Skip to content

Conversation

@briannadelvalle-datadog
Copy link

@briannadelvalle-datadog briannadelvalle-datadog commented Oct 15, 2025

Description

  1. Use healthchecks instead of wait-for-it -- reduces chance of bad race conditions breaking storedog in labs
  2. Add Makefile functionality
  3. Add scripts to generate docker-compose.yml files from docker-compose.dev.yaml. (One is intended for pre-release, another is for testing the frontend prod build target while using the dev docker compose file.)
  4. Update readme and add service-level readmes (and a FEATURES.md file)
  5. Improve frontend service image: multilayer builds, use build targets
  6. Add a simple env.development.template for TCD use.

Frontend build times

Tested with the help of Cursor/Claude.

Dockerfile Clean build Build env vars change (second build) Source code change (third build)
Production build target 39.35s 8.01s 9.67s
Old Dockerfile 47.43s 27.48s 18.90s

Image Sizes

Tested with the help of Cursor/Claude.

Dockerfile Size
Production (Multi-stage) 301.4 MB
Old Dockerfile (Single-stage) 812.8 MB

How to test

Test the healthchecks

  1. Run make up to build the dev containers.

Test the frontend prod build target

  1. In the Makefile, set ENV=dev-frontend-prod.
  2. Run make up clean.

Test the dockerfile generation script

  1. Run make prepare-release.
  2. Check the docker-compose.generated.yml file and answer Y/N in the terminal.

Test the Makefile updates

  1. Run make help to see the commands.

…tation; add transform_compose.py script and unit tests for compose transformations.
…nction for generated files in transform_compose.py
…rget, and build args in docker-compose template; refine regex pattern for build section replacement in transformation logic.
…opment and production environments, including environment variable configurations and dependency installations.
… function for selecting the appropriate Docker Compose file based on the ENV variable. Simplify commands for starting, stopping, and managing containers in both development and production environments.
…ariables for frontend service; add port mapping for local development.
…th NEXT_PUBLIC_DD variables for frontend service configuration.
…nv var stuff to env templates, move feature stuff to feature.md
…BLIC_DD variables for consistency in frontend service configuration.
… with NEXT_PUBLIC_DD variables for consistency in frontend service configuration.
console.error(e)
setLoading(false)
}
}, [adsPath, getRandomArbitrary, setData, setLoading])

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

React said that this wasn't needed here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, it's not a dependency

@@ -1,29 +1,134 @@
FROM node:20 AS builder
FROM node:lts-alpine AS base

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To mitigate a security vulnerability in other image

@briannadelvalle-datadog briannadelvalle-datadog marked this pull request as ready for review October 21, 2025 19:25
@@ -1,4 +1,5 @@
module.exports = {
output: 'standalone',

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for the optimized production builds (production build target)

@briannadelvalle-datadog briannadelvalle-datadog marked this pull request as draft October 21, 2025 19:52

settings.json

docker-compose.dev.frontend-prod.yml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this last one left here on purpose?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is only for testing the frontend prod build target.
Can't test it with the regular docker-compose.yml because it's not in the storedog image.
Can't test it with the docker-compose.dev.yml because of the volume mounts.
I'm adding a script and a make command to generate this file, but there's no reason to add it to source control.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For more context, the prod build creates a server.js file and the command is node server.js. If we're mounting the entire service directory, we end up losing that file.

labels:
com.datadoghq.ad.logs: '[{"source": "python"}]'
com.datadoghq.ad.logs: '[{"source": "python", "service": "store-discounts"}]'
com.datadoghq.tags.env: '${DD_ENV:-development}'
Copy link
Collaborator

@arosenkranz arosenkranz Oct 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we're adding service level com.datadoghq.tags.* back in some definitions and not others? IIRC we removed them not long ago because Shawn said they were redundant if we had proper labelling elsewhere (e.g. setting DD_ENV at the agent-level means all other services will follow suit).

I could be mistaken on this, and keeping them doesn't do any harm, so not really a blocker imo

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was an accident on my part. I was using my RUM course's branch as a starting point, but there have been updates since that branch was made.



.gradle/
Gemfile.lock
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You remove Gemfile.lock but since it's already been checked-in, it won't retroactively ignore it. Need to either delete the file (this is fine, because the docker image sets it up anyway) or reset the git cache so the .gitignore gets adhered to.

Also, I think to avoid this in the future, we should probably create/update a .dockerignore file that has node_modules, .git, and Gemfile.lock

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol oh yeah duh 🤦 ... I don't know enough about Gemfile.lock. Is that something we want under source control?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants